Just curious, which of the following are we looking to achieve for testpoolswap?

1. Always use direct path if available
2. Use best path (implying some composite path may yield an amount greater than direct - assuming that's possible)

Asking because if (2) is preferred, the logic could instead be in CPoolSwap::CalculatePoolPaths.

Just curious, which of the following are we looking to achieve for testpoolswap?

1. Always use direct path if available

2. Use _best_ path (implying some composite path may yield an amount greater than direct - assuming that's possible)

Asking because if (2) is preferred, the logic could instead be in CPoolSwap::CalculatePoolPaths.

Good question. Here I addressed the issue by going for the first option but that might not always be the best scenario.
Another option would be to add "composite" to the accepted path values which would always test for compositeswap.
Then we would have:

• direct: Always test for a poolswap
• composite: Always test for a compositeswap
• auto: Use a direct swap via poolswap if available (as currently in this PR) or go through compositeswap
• [poolpairs_ids]: Try through a custom path

With this additional path, a user could try for direct vs composite and choose the best of two paths (scenario 2).

Just curious, which of the following are we looking to achieve for testpoolswap?

1. Always use direct path if available

2. Use _best_ path (implying some composite path may yield an amount greater than direct - assuming that's possible)

Asking because if (2) is preferred, the logic could instead be in CPoolSwap::CalculatePoolPaths.

Good question. Here I addressed the issue by going for the first option but that might not always be the best scenario. Another option would be to add "composite" to the accepted path values which would always test for compositeswap. Then we would have:

• direct: Always test for a poolswap
• composite: Always test for a compositeswap
• auto: Use a direct swap via poolswap if available (as currently in this PR) or go through compositeswap
• [poolpairs_ids]: Try through a custom path

With this additional path, a user could try for direct vs composite and choose the best of two paths (scenario 2).

saw this later. I guess it could be possible that a composite swap yields more than the direct swap 🤔
I think the main problem is that CalculateSwaps is not able to handle the scenario where only the direct pool is available and no other path. need to write a unit test and confirm it.

Just curious, which of the following are we looking to achieve for testpoolswap?

1. Always use direct path if available

2. Use _best_ path (implying some composite path may yield an amount greater than direct - assuming that's possible)

Asking because if (2) is preferred, the logic could instead be in CPoolSwap::CalculatePoolPaths.

Good question. Here I addressed the issue by going for the first option but that might not always be the best scenario. Another option would be to add "composite" to the accepted path values which would always test for compositeswap. Then we would have:

• direct: Always test for a poolswap
• composite: Always test for a compositeswap
• auto: Use a direct swap via poolswap if available (as currently in this PR) or go through compositeswap
• [poolpairs_ids]: Try through a custom path

With this additional path, a user could try for direct vs composite and choose the best of two paths (scenario 2).

composite here would mean "use the best possible composite swap path"? I would think that's a pretty niche use-case 😮 (ofc I could be wrong haha).
Regarding the user trying both options - we probably want to avoid having to make 2 RPCs as it would be a performance / UX impediment for wallet users. So since the user is mainly concerned with "the best option", then we should just give em that straightaway -> this is an existing use-case in defichain wallet (BirthdayResearch/jellyfishsdk#1065)

saw this later. I guess it could be possible that a composite swap yields more than the direct swap 🤔 I think the main problem is that CalculateSwaps is not able to handle the scenario where only the direct pool is available and no other path. need to write a unit test and confirm it.

Agree. Deeper - CalculatePoolPaths doesn't ever consider a direct path. So we could just have the logic there instead.
Then auto would return the "best" among the direct and possible composite paths, since the direct path is also included in the CalculateSwaps evaluation.

The logic behind it was that we have two different RPCs for poolswap and compositeswap.
In that case, testpoolswap composite would give the result of a RPC compositeswap call while testpoolswap direct would give the result of a RPC poolswap call.

The logic behind it was that we have two different RPCs for poolswap and compositeswap. In that case, testpoolswap composite would give the result of a RPC compositeswap call while testpoolswap direct would give the result of a RPC poolswap call.

Ah I see what you mean. I think just fixing the "auto" path to give the best swap (be it a direct or composite) would suffice to fix the issue at BirthdayResearch/jellyfishsdk#1065.

Regarding the 'composite' option - really depends if ain would like to support this haha but there's no immediate use-case for it I believe